[Fix-4444][admin] Scope job monitor polls to the job tenant - #4582

Purpose of the pull request

A reused job monitor worker can keep another tenant's context. When Flink reports a terminal state, the tenant-filtered database update then matches no row, but monitoring stops and the job list remains RUNNING until a manual refresh.

Scope each poll to the loaded job instance's tenant and restore the caller's context afterwards. This addresses a reproducible tenant-dependent cause of the stale-status symptom in #4444 on dev. The earlier #4451 bypass is present in v1.2.5 but absent from the pinned dev base. This change preserves the existing bypass flag; when filtering is enabled, it stays enabled.

Brief change log

• Bind the job tenant around refresh, alerts, and metrics, restoring the previous context in finally.
• Add regression coverage for cross-tenant persistence, sequential jobs, exceptions, empty context, and manual refresh.
• Isolate the regression fixtures' static services and alert state from other tests with a test-only classloader.

Verify this pull request

The regression uses a loopback Flink REST fixture reporting FAILED, H2, and the production MyBatis tenant interceptor. Before the fix, the database remains RUNNING; after the fix, it becomes FAILED and the other tenant's row is unchanged. The suite fails 6 of 7 tests before the fix and passes all 7 afterwards.

Verified on JDK 11:

./mvnw -B -pl dinky-admin -am -P prod,flink-single-version,flink-1.20,maven-central -Dtest=FlinkJobTaskTest -Dsurefire.failIfNoSpecifiedTests=false -Dspotless.check.skip=true test
./mvnw -B spotless:check -P flink-all

All 47 modules in the dependent backend reactor compiled. No live YARN ResourceManager/HA deployment was exercised, and the original deployment's root cause is unconfirmed. The reproduced fault requires a wrong inherited tenant with filtering enabled; this change does not repair pre-existing inherited bypass flags.